This invention is in the technical field of enterprise data management systems, and, in particular, product design management systems and methods.
Most organizations, and particularly businesses and business entities, need to coordinate a wide variety of different information and information types during the course of their daily activities. As an example, consider an organization that manufactures electronic products. The organization must coordinate the concept, design, development, prototyping, pilot production, scale-up and launch of it's various new products. Manufacturing must produce the products at high volume, and insure that the products meet quality standards. Service and support departments must monitor the product performance in the field, and help support customers. As more and more environmental regulations come into effect, even disposal of products now becomes highly complex, as various types of “green” regulations that differ from country to country.
Other company functions must be integrated into this overall product management framework. Sales, marketing and customer support must manage relationships with customers, accountants must manage the financial record, supply chain managers must manage orders and relationships with suppliers, and the company's personnel department must manage employees, and insure that staffing levels and employee needs are met in a way that allows the organization to meet its overall objectives.
In order to handle this type of complexity, companies such as Agile Software Corporation, and other vendors, have introduced sophisticated computer systems that can collect data from these various departments and present the data in a way that lets the organization run its operations electronically. These systems, often called “Product Lifecycle Management” (PLM) systems, function by using data translation or decoding “middleware” that extracts data from each department's specialized software programs (e.g. the design department's various CAD system's, the accounting department's financial software, various specialized databases and so on. The PLM system takes this multi-source data, collates it into a comprehensive database, and presents it to the organization in a form that allows authorized individuals full access to the data that they need to do their respective tasks, regardless of where the data originally came from. Thus a design engineer can get full access to accounting cost data for a particular product subcomponent, can see what the manufacturing yields are for that product, can track customer complaints, and so on. Such PLM systems, such as the Agile 9 system produced by Agile Software Corporation, San Jose, Calif. greatly increase organizational effectiveness, and are presently on a rapid adoption curve worldwide. Examples of prior PLM art include U.S. Pat. Nos. 7,124,150 and 7,010,580.
Although organizations and products are often extremely complex, even the most complex organizations, businesses, and products often rest on some very simple fundamental principles (i.e. “meta ideas”, “fundamental requirements”, or “intent”). Often revolutionary new products and business opportunities are, at the heart, so simple that they can be written on the back of a napkin. Automobile companies were started on the “back of a napkin” idea of rep lacing a horse by meshing an engine with a carriage. As the concepts are developed further, this fundamental concept/requirement/intent (carriage with an engine and no horse) is modified with additional requirements, which usually change with time.
As an example, Henry Ford added additional requirements to the root (initial, base, or trunk) “horseless carriage” concept. He added additional (secondary, side, branch) concepts that the automobile should also be inexpensive (allowing it to be mass produced on a large scale) and reliable. In Ford's mind, these were the main secondary criteria, as exemplified by his famous statement: “any color, so long as it is black.”
As time when on, however other automobile companies, such as General Motors, realized that appealing to the customer's sense of style was also important, because this would give the automobile company a competitive advantage. As a result, other companies modified Ford's “low cost” requirement to incorporate an additional high level requirement that the auto should also be visually attractive (colors other than black).
As time went on, still more high-level requirements were added to the automobile requirements “tree”. Some of these later requirements include safety, and environmental friendliness. Note that requirements lists are often referred to as requirements “trees”, because many requirements depend upon and branch out from a few fundamental requirements, and the diagrams of these lists often resemble trees. A complex device such as an automobile has a huge requirements tree that extends many levels downward.
Ideally every activity that an organization performs should be consistent with the organization's high-level requirements “tree”. If the organization is attempting to design a sports car, ideally the design engineers should not select a heavy diesel engine. If the organization is attempting to build a reliable car, the accountants and the supply chain managers should not necessarily choose the cheapest component if it has a high failure rate.
Unfortunately, as product and organizational complexity grows, it becomes very easy for both workers and management to lose track of the big picture, and instead focus on optimizing their individual areas at the expense of the big picture. Design and manufacturing engineers may try to simplify the automobile design process by putting the gas tank where it is easiest to assemble, rather than where it is safest. Accountants and supply chain managers may optimize costs by choosing the cheapest vendor, and forget about reliability, and so on.
Complex products often have many requirements, many of which may not be fully understood when the product is first conceived, and which may later turn out to impact each other in unexpected ways. Because of complex dependency issues, design changes to one area may often end up having an unexpected impact on the design specification for a very different area. Thus, particularly when complex products are being designed by large teams, the design process is often a series of negotiations, sometimes tense negotiations, between different team members, as all strive to come up with a set of design specifications that both meets customer demands, and is actually feasible.
In order to facilitate the design of complex products and systems, requirements management software systems have been developed to automate the task of defining the various requirement levels in a complex project, and managing the various requirement changes and conflicts that occur during the course of product development. Such products, exemplified by the Telelogic DOORS® requirements management system, Telelogic corporation, Malmö Sweden, are becoming popular for analyzing requirements for complex systems.
Examples of prior requirements manager art include U.S. patent applications 2004/0073888, and 2005/0149917.
Unfortunately, even with modern PLM systems to manage complex enterprises, the problems of ensuring that individual workers are aware of how their decisions impact a product or an organization from the “big picture” standpoint still persists.
Present day PLM systems allow a design engineer and an accountant to quickly collaborate in order to pick the cheapest part for a component, but they don't necessarily insure that this process is any wiser. Rather, present PLM systems just make the selection process much faster. What is needed is some way to convey “wisdom”, that is a way to rapidly and almost automatically let individual workers understand how their particular activities and decisions impact the project as a whole.
Similarly, although requirements management (RM) systems have been devised that allow design engineers and managers to rapidly collaborate and sort out design priorities for a project, these prior art RM systems primarily confine their domain expertise to the design process. Earlier requirement management art is largely silent on how to automatically use requirements data to help manage the complex day-to-day organizational activities, which comprises “PLM space”.
Thus, there exists a need in the art for a system and method that better addresses PLM management needs for automatically using requirements data for collaboration. As will be seen, the invention accomplishes this in an elegant manner.